Upgrade to wgpu 28

> [!important]
> This can't merge until bevyengine/naga_oil#132
does, and the dependency is updated from my fork to the release.
> 
> Also requires wgpu 28 in dlss_wgpu:
bevyengine/dlss_wgpu#17

> [!note]
> This does not enable mesh shaders, and neither does the naga_oil PR. I
chose to do an upgrade first, then go back and see about mesh shaders.

Here's a general list of changes and what I did. Commits are grouped by
feature except for the last one, which enabled solari when I ran the
solari example.

## MipmapFilterMode is split from FilterMode

- Split MipmapFilterMode from FilterMode #8314:
gfx-rs/wgpu#8314

solution: implement From for `MipmapFilterMode`/`ImageFilterMode` since
the values are the same. The split was because the spec indicates they
are different types, even though they have the same values.

## Push Constants are now Immediates

- gfx-rs/wgpu#8724

immediate_size is [a
u32](https://docs.rs/wgpu/28.0.0/wgpu/struct.PipelineLayoutDescriptor.html#structfield.immediate_size)
so use that instead of `PushConstantRange`

## Capabilities name changes

- gfx-rs/wgpu#8671

Got new list from
https://github.com/gfx-rs/wgpu/blob/trunk/wgpu-core/src/device/mod.rs#L449
and copied it in.

## subgroup_{min,max}_size moved from Limits to AdapterInfo

- gfx-rs/wgpu#8609

Update the limits to have the fields they have now, mirror the logic
from the other limits calls.

## multiview_mask

- gfx-rs/wgpu#8206

set to None because we don't use it currently. Its vaguely for VR.

## error scope is now a guard

- gfx-rs/wgpu#8685

retain guard and then pop() it later


---

I made one mistake during the PR, thinking set_immediates was going to
be the size of the immediates and not the offset. I'd like reviewers to
take a look at immediates offset and size sites specifically just in
case I missed something.

Here's a bunch of examples running

<img width="1470" height="1040" alt="screenshot-2025-12-24-at-16 47
22@2x"
src="https://github.com/user-attachments/assets/83dcf4c8-69f5-480a-b724-86598530f25a"
/>
<img width="1470" height="1040" alt="screenshot-2025-12-24-at-16 48
44@2x"
src="https://github.com/user-attachments/assets/46d897fa-1ab2-44ef-8055-fe2fce740dbc"
/>
<img width="1470" height="1040" alt="screenshot-2025-12-24-at-16 49
10@2x"
src="https://github.com/user-attachments/assets/6ae7a9bf-0473-4800-8dfc-233a6a41d6df"
/>
<img width="1470" height="1040" alt="screenshot-2025-12-24-at-16 49
31@2x"
src="https://github.com/user-attachments/assets/89f84a26-cfbd-4196-bca8-111c3d20ba7b"
/>


## Known Issues

> [!NOTE]
> 
> There are no current known issues. Everything previous has been
solved.

- [x] enable extensions can not be written in naga oil in a way that
allows them to be used in composed modules.

Update: this was fixed by introducing a flag in naga-oil to force
shaders to allow ray queries in composed modules when using bevy_solari.
This is temporary and will be different in WESL-future.

<details><summary>old explanation</summary>
This is blocking solari from working on nvidia (solari runs successfully
on macos m1) because it needs `enable wgpu_ray_query;`. Putting the
declaration before `#define_import_path` means it gets stripped out
(afaict), and putting it after results in

```
error: expected global declaration, but found a global directive
  ┌─ embedded://bevy_solari/scene/raytracing_scene_bindings.wgsl:3:1
  │
3 │ enable wgpu_ray_query;
  │ ^^^^^^ written after first global declaration
  │
  = expected global declaration, but found a global directive
```

</details>

- [x] dlss_wgpu mixes apis which [causes panics
now](bevyengine/dlss_wgpu#17 (comment)).

<details><summary>Previous notes as dlss_wgpu was being fixed
here</summary>

The wgpu release notes don't mention which PR this was introduced in,
only saying:

> Using both the wgpu command encoding APIs and
CommandEncoder::as_hal_mut on the same encoder will now result in a
panic.

It was caused by gfx-rs/wgpu#8373 which claimed
to not know of any use cases

> With record on finish, the actual ordering on the command buffer is
deeply counter intuitive (all as_hal would come first) and I think it
additionally was just flat out broken in some ways
> -
https://discord.com/channels/691052431525675048/743663924229963868/1453786307099758683

Possible path forward is using multiple command buffers:
https://discord.com/channels/691052431525675048/743663924229963868/1453795633503670415

</summary>

---------

Co-authored-by: robtfm <50659922+robtfm@users.noreply.github.com>